Automated trust negotiation

ABSTRACT

Distributed software subjects face the problem of determining one another&#39;s trustworthiness. The problem considered herein is managing the exchange of credentials between strangers for the purpose of property-based authentication and authorization when credentials, authenticating properties of the subject, are sensitive. An architecture for trust negotiation between client and server is presented. The notion of a trust negotiation strategy is introduced with respect to an abstract model of trust negotiation. Two strategies with very different properties are defined and analyzed. A language of credential expressions is described, with two example negotiations illustrating the two negotiation strategies ongoing work on policies governing credential disclosure and trust negotiation is disclosed.

Cross Reference to Related Applications

[0001] This application is an improvement on the inventors' prior U.S.patent application Ser. No. 09/260,249, filed Mar. 2, 1999 (IBM docketnumber UK9-99-007) entitled “TRUST NEGOTIATION IN A CLIENT/SERVER DATAPROCESSING NETWORK USING AUTOMATIC INCREMENTAL CREDENTIAL DISCLOSURE”which is commonly assigned with the present application. The PCTapplication corresponding to this related application has been publishedon Sep. 8, 2000, under the publication number WO00/52557.

BACKGROUND OF THE INVENTION

[0002] The present invention relates to the problem of distributedsoftware components, and how such components can communicate in a isreliable and secure context, for example in an e-business environment.

[0003] Distributed software subjects face the problem of determining oneanother's trustworthiness. Current mainstream approaches to establishingtrust presume that communicating subjects are already familiar with oneanother. There are essentially two approaches based on this assumption.The first is identity-based: identifying a subject is often a sufficientbasis for doing business. The second is capability-based: subjectsobtain capabilities that are specific to the resources they wish to use.Both approaches require that familiarity be established out of band.Identity- and capability-based approaches are both unable to establishtrust between complete strangers. Other solutions are needed in opensystems, such as the web, where the assumption of familiarity isinvalid.

[0004] Property-based digital credentials [1] (see the end of thisdescription for full details of references) (or simply credentials) arethe on-line analogues of paper credentials that people carry in theirwallets. They present a promising approach to trust establishment inopen systems. Credentials, which generalize the notion of attributecertificates [22], can authenticate not just the subject's identity, butarbitrary properties of a subject and its relationships with othersubjects. Those properties can be used, for instance, when a clientattaches appropriate credentials to service requests, to support serviceauthorization.

[0005] Trust establishment between strangers is particularly importantin the context of e-business. Credential exchange between strangerspromises to enable software agents to establish trust automatically withpotential business partners. For instance, a software agent might becharged with finding new candidate suppliers of commodity goods andservices. Even when an automatically generated list of such candidateseventually would be culled by a human, information such as requirementsand availability of the desired goods might be sensitive, requiringtrust establishment as part of the automated process of identifyingcandidates.

[0006] Credential-based authentication and authorization systems can bedivided into three groups: identity-based, property-based, andcapability-based systems. The original, public key certificates, such asX.509 [22] and PGP [20], simply bind keys to names (although X.509version 3 certificates later extended this binding to generalproperties). Such certificates form the foundation of identity-basedsystems, which authenticate a subject's identity or name and use it asthe basis for authorization. Identity is not a useful basis for our aimof establishing trust among strangers. Property-based credentials wereintroduced by Bina et al. [1] to incorporate the binding of arbitraryattributes. Trust establishment between strangers can be based on theproperties of the subjects without requiring prior contact betweensubjects or their designees. Systems have emerged recently that useproperty-based credentials to manage trust in decentralized, distributedsystems [6][12][15][18]. Capability-based systems [2][3][4][21],discussed further below, manage delegation of authority to operate on aparticular application. Pure capability-based systems are not designedfor establishing trust between strangers, since clients are assumed topossess credentials that authorize specific actions with the applicationserver.

[0007] Winslett et al. [19] focus on establishing trust betweenstrangers. They present an architecture for using credentials toauthorize access to distributed resources. Client and server securityassistants manage both the credentials and the policies governing accessto sensitive resources. They emphasize the need for credential andpolicy exchange with little intervention by the client. Seamons et al.[15] continue in this vein, developing policies written in Prolog thatuse credentials and credential attributes to authenticate clients toroles that have attributes, which can be used in authorizationdecisions. This work addresses credential sensitivity by using mobilepolicies to support private client selection of credentials to submitfor authorization.

[0008] Johnston et al. [11] use both attribute certificates(property-based credentials) and use-condition certificates (policyassertions) to determine access control. Use condition certificatesenable multiple, distributed stakeholders to share control over accessto resources. In their architecture, the policy evaluation engineretrieves the certificates associated with a user to determine whetherall use conditions are met. The certificates are assumed not to besensitive.

[0009] The Trust Establishment Project at the IBM Haifa ResearchLaboratory [12][13] has developed a system for establishing trustbetween strangers according to policies that specify constraints onattribute-contents of public-key certificates. Servers use a collectorto gather supporting credentials from issuer sites. The system assumesthat credentials are not sensitive. The companion Trust Policy Language(TPL) is a special-purpose logic programming language, with XML syntax,that maps certificate holders to roles. TPL policies also map theissuers of each supporting credential to a role. These roles can be usedby existing role-based access control mechanisms.

[0010] The capability-based KeyNote system of Blaze et al. [2][3][4]manages delegation of authority. A KeyNote credential is an assertionthat describes the conditions under which one principal authorizesactions requested by other principals. A policy is also an assertionthat delegates authority on behalf of the associated application tootherwise untrusted principals.

[0011] Thus an application's policy defines the root of all delegationchains. KeyNote credentials express delegation of authority in terms ofactions that are relevant to a given application.

[0012] KeyNote policies do not interpret the meaning of credentials forthe application. This is unlike policies designed for use withproperty-based credentials, which derive roles from credentialattributes, or otherwise bridge the divide between the application andcredentials that were issued for unrelated purposes. The IETF SimplePublic Key Infrastructure [21] uses a similar approach to that ofKeyNote by embedding authorizations directly in certificates.

[0013] The Delegation Logic (DL) of Li et al. [9] [10] combines aspectsof capability and property-based approaches. While this logicallywell-founded model focuses directly on authorization, rather than onauthenticating subjects to roles, it allows authorizations to bedelegated based on properties of subjects, which can be represented byDL credentials.

[0014] SSL [6], the predominant credential-exchange mechanism in use onthe web today, and its successor TLS [6][7], support credential exchangeduring client and server authentication. There is no opportunity for theserver to authenticate any information about the client beforedisclosing server credentials. That is, sensitive server credentialscannot be protected. Furthermore, if the credential disclosed by theserver does not satisfy the client, the client has no opportunity torequest additional credentials from the server. This presents a seriousproblem when the client and server are strangers: it is unlikely thatany single issuer would be an acceptable authority on all serverattributes of interest to all potential clients.

[0015] Thus a particular problem exists in automated trust establishmentbetween strangers through credential exchange when credentials arethemselves potentially sensitive. A sensitive credential containsprivate information. For instance, access to a credential containingmedical information could be restricted to primary care physicians andHMO staff. Access to a credit card credential could be limited tobusinesses that are authorized to accept a VISA card and that adhere toguidelines for securing credit card numbers. Prior trust establishmentsystems based on credential exchange have addressed credentialsensitivity only manually, requiring a user at the client to decidewhich credentials to submit to each new service. In 2 addition torequiring human intervention, this approach provides to the human makingthe trust decision no assistance in evaluating the trustworthiness ofthe server. A partial solution to these problems is presented in [17]and [18]. However these earlier documents do not disclose any extensiveor rigourous analysis of two negotiation strategies, or provide aprototype trust-negotiation system.

SUMMARY OF THE INVENTION

[0016] The present invention presents an architecture for client-serverapplications in which client and server each establishes a credentialaccess policy (CAP) for each of its credentials. A credential isdisclosed only when its CAP is satisfied by credentials obtained fromthe opposing software agent. When an agent needs additional credentials,it can request them. Credentials flow between the client and serverthrough a sequence of alternating credential requests and disclosures,which we call a trust negotiation. A formal, abstract model of trustnegotiation is disclosed and then used to specify negotiationstrategies.

[0017] A negotiation strategy determines characteristics of anegotiation such as which credentials are requested and disclosed, andwhen the negotiation is halted. Two negotiation strategies are formallyspecified and analysed herein finding them efficient and effective inestablishing trust whenever possible.

[0018] The two negotiation strategies differ in the number ofcredentials that are exchanged. Participants using the first strategyturn over all their credentials as soon as their CAPs are satisfied,without waiting for the credentials to be requested. For this reason wecall it an eager strategy. It is simple and clear; however, it disclosesmore credentials than necessary to achieve most trust requirements.Participants using the second strategy exchange credential requests thatfocus the credential exchange, achieving a kind of local minimality ofdisclosures. Because it is stingy with disclosures, we call it aparsimonious strategy. However, it has the drawback that the credentialrequests can disclose sensitive information about the subjects'credentials and properties. These tradeoffs are investigated below.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Preferred embodiments of the invention will now be described indetail by way of example only with reference to the following drawings:

[0020]FIG. 1 is a schematic diagram illustrating the role of securityagents in trust negotiation;

[0021]FIG. 2 illustrates the set of credentials owned by a client andserver;

[0022]FIG. 3 schematically illustrates the relationship betweencredentials and roles; and

[0023]FIG. 4 illustrates a typical Web implementation of trustnegotiation.

DETAILED DESCRIPTION

[0024] 1. Introduction

[0025] This detailed description is split into several sections for easeof understanding. Section 2 introduces credentials and explains how theycan be used to establish trust between strangers. Section 3 introducescredential sensitivity and the problems it creates. Section 4 presents atrust negotiation architecture and an abstract model of trustnegotiation that is used in Section 5, where eager and parsimoniousnegotiation strategies are formally specified and rigorously analyzed.Section 6 presents two expression languages that can be used within thetrust negotiation architecture to express CAPs and credential requests.Section 7 presents two examples of trust negotiation, illustrating theeager and parsimonious negotiation strategies, respectively. Section 9concludes and discusses future areas of potential research.

[0026] 2. Credential-based Trust

[0027] A credential is a digitally signed assertion by the credentialissuer about the credential owner. Credentials can be made unforgeableand verifiable by using modern encryption technology: a credential issigned using the issuer's private key and verified using the issuer'spublic key [114]. A credential aggregates one or more attributes of theowner, each consisting of an attribute name/value pair and representingsome property of the owner asserted by the issuer. For our purposes, acredential is specifically not required to identify the owner. Eachcredential also contains the public key of the credential owner. Theowner can use the corresponding private key to answer challenges orotherwise demonstrate possession of that private key to establishownership of the credential. The owner can also use the private key tosign another credential, owned by a third subject. In this way,credential chains can be created, with the owner of one credential beingthe issuer of the next credential in the chain.

[0028] Credential chains can be submitted to trace a web of trust from aknown subject, the issuer of the first credential in the chain (e.g.,subject A in Table 1), to the submitting subject, in which trust isneeded. The submitting subject is the owner of the last credential inthe chain (e.g., subject C) and can demonstrate ownership of thatcredential, as outlined above. Supporting credentials are owned bysubjects with whom the submitting subject has a direct or indirectrelationship, and, although they are not owned by the submittingsubject, the submitting entity does collect, keep, and submit copies ofthem. Each supporting credential contains the public key whoseprivate-key mate signed the next credential in the chain, enablingreliable verification that the attribute claims made in that nextcredential were made by the owner of the supporting credential.

[0029] The submitted credentials attempt to demonstrate a (possiblyindirect) relationship between the submitting subject and the knownsubject that issued the first credential in the chain. The nature ofthat relationship can be inferred by inspecting the attributes of thecredentials in the chain. Multiple chains can be submitted to establisha higher degree of trust or to demonstrate additional properties of thesubmitting subject and its relationships with known subjects. TABLE 1Credential 1 Credential 2 Type = reference type = reference Relationship= shippingClient relationship = shipper Issuer = subjectAKey → issuer =subjectBKey Owner = subjectBKey owner = subjectCKey

[0030] Table 1 shows two credentials forming a chain. Credential 2 wasissued by Subject B, the owner of Credential 1. In Credential 1, subjectA asserts that subject B is a consumer of shipping services. InCredential 2, subject B asserts that subject C is a shipper. If we trustsubject A's judgment that subject B is a consumer of shipping,presumably subject B is in a position to know that subject C is ashipper. Additional credentials owned by subject B can be used toengender trust that subject B is a reliable authority on the assertedattributes of subject C.

[0031] A credential expression, ψ, is a logical expression overcredentials with constraints on their attributes. A credentialexpression serves to denote the combinations of credentials, C, thatsatisfy it. We call those combinations the solutions of the expression.For the purpose of trust negotiation, credential expressions can be usedto convey requests for credentials between client and server. In thiscontext, credential expressions denote chains of credentials that endwith credentials owned by the submitting subject. A credentialexpression can also be used as a policy governing access to a resource.Access to the resource is granted to a subject when a solution ispresented that consists of one or more chains ending in credentialsowned by the subject. The resource is unlocked by the solution.

[0032] A policy is mobile if it is sent from one subject to another aspart of automatic or semiautomatic trust establishment. Mobile policiesare used in prior systems to express requirements a client must meet toobtain service. When insufficient credentials accompany a servicerequest, the server returns the service-governing policy (SGP).Communicated in this way, the SGP acts as a request for the credentialsneeded to unlock the resource. Such mobile policies enable clients toselect a set of credentials whose submission will authorize the desiredservice. The client can then issue a second request for service withthose credentials attached, and upon verifying the credentials, theserver provides the desired service. Policy mobility has two significantadvantages. First, it offloads from the server to the client the work ofsearching the client's credentials. Second, it enables trust to beestablished in the client without the client revealing irrelevantcredentials.

[0033] 3. When Credentials are Sensitive

[0034] A client wishing to do business with a new service may beunwilling to disclose sensitive credentials until some degree of trusthas been established in that service. Current credential systems do notaddress credential sensitivity. The decision to disclose a sensitivecredential to a new service is left up to a user at the client. Morespecifically, client-credential submission policies specify whichcredentials can be submitted with any request to a specified class ofservice and which credentials require explicit authorization before theyare submitted. This mechanism requires a user be available to make trustdecisions when new service classes are contacted. It does not addresshow the user decides to trust a service.

[0035] In [19], Winslett et al. recognize the potential to use servercredentials to establish client trust, though they focused mainly onserver trust in clients. They present detailed mechanisms for clients tosubmit credentials to servers. Each service provider establishes apolicy governing access to its resources. Upon receiving a request withinsufficient credentials attached-often the case on first access-asecurity agent representing the server sends the client an explanationof the relevant portions of the policy. The client's agent analyzes theserver's policy to determine which credentials are needed to support theservice request. It makes a decision on which credentials to send to theserver (based on a pre-defined client submission policy and interactionwith the user). The client agent then attaches the selected credentialsto subsequent requests for the service.

[0036] Winslett et al. note the relevance of such machinery for thereverse scenario, in which servers encourage clients by presenting theirown credentials, and a client may request credentials from a server.Such a reversal provides a good basis for clients establishing the trustin servers required before disclosing sensitive credentials. However,Winslett et al are unclear about the details of how this kind of trustcan be established.

[0037] The preferred embodiment of the present invention provides amethod of automating the establishment of trust between strangersthrough incremental exchange of sensitive credentials. One simplisticapproach to managing the exchange of sensitive credentials thatunfortunately does not work is as follows. The client establishes apolicy identifying credentials required from the server prior to theclient disclosing any credentials. The client sends this policy to theserver as a counter request whenever it receives from the server acredential request, such as a SGP. It would then be useless for theserver to request client credentials before disclosing its owncredentials, as doing so would introduce a cyclic dependence anddeadlock. This simplistic approach fails because it governs all clientcredentials with the same policy, so each request by the server forclient credentials leads to an identical counter request from theclient.

[0038] 4. Negotiation Architecture and Model

[0039] Section 4.1 presents a high-level architecture that supportsfully automated trust negotiation between client and server. Section 4.2then introduces an abstract model of trust negotiation. The model isused in Section 5 to formalize and analyze two negotiation strategies.

[0040] In both architecture and model, each credential is protected by aCAP that controls the credentials disclosure based on credentialspresented by the other negotiation participant. Throughout, credentialsare disclosed only in observance of these CAPs. In one of the twonegotiation strategies presented in Section 5, credential requests areexchanged to guide the credential exchange.

[0041] 4.1. Trust Negotiation Architecture

[0042] Each of our negotiation participants is represented in trustnegotiations by a security agent (SA), as in the simple negotiations ofChing et al. [5] and Winslett et al. [18]. The role of the SA isillustrated in FIG. 1, which depicts the client security agent (101) andthe server security agent (201) and several resources and contextualfactors that each SA considers during negotiation. The client SA managesthe disclosure of client credentials (102) and the server SA managesdisclosure of server credentials (202). Like any protected resource,each credential is governed by an access policy (103, 203) that has thesame form as a SGP. The CAP identifies credentials from the othernegotiation participant that would unlock disclosure of the localcredential to that subject.

[0043] The client (10) initiates the trust negotiation by making aservice request. The client SA intercepts the request and relays it tothe server SA. The application service (20) is accessible only via theserver SA. Upon receiving a request for service (305), the server SAmakes an authorization decision based on the appropriate SGP (206). Whenthe client SA is familiar with the SGP, it can attach appropriatecredentials (304) to the service request so that the service will beauthorized. The server SA determines whether the credentials that arrivewith the service request satisfy the SGP. If the policy is satisfied,the trust negotiation has completed successfully; the service isauthorized and the request is forwarded to the application server, whichprovides the service to the client (this step not shown in figure).

[0044] Initially, the client is unfamiliar with the SGP, so attachingsatisfactory credentials to an initial service request is impractical. Atrust negotiation strategy can overcome this problem by using mobilepolicies. When a server SA receives a request for service withoutsufficient credentials attached to satisfy the SGP, it sends the SGP tothe client SA as a request for client credentials (302). The client SAcan then select a combination of credentials that satisfies the SGP, andcan attach those credentials (304) to a repetition of the originalservice request (305).

[0045] An important issue in this scenario not addressed in previoustrust systems is how to enable the client SA to make independent trustdecisions about which credentials to provide to an unfamiliar server.Our SAs use CAPs (103, 203) when selecting credentials to disclose. Ifthe client SA cannot satisfy the SGP by using credentials whose CAPs areunprotected, it can, as the negotiation instigator, introduce furtherstages to the trust negotiation by requesting server credentials (303).These stages seek to build mutual trust through credential exchange,eventually to unlock client credentials that satisfy the SGP. Clientcredentials are unlocked by incoming server credentials (301); however,as an optimization, the client may also cache and use for this purposeserver credentials it received in prior stages (104). (The abstractmodel of trust negotiation introduced in Section 4.2 does not capturethis optimization.) In each negotiation stage, the active subjectresponds to an incoming request for credentials either by providingcredentials, by formulating a counter request for credentials (302,303), or both. In some strategies, the client SA can also repeat one ofits previous request (105) for credentials that has not yet beensatisfied. By exchanging credentials and requests for credentials, thetwo SAs endeavor to establish trust required to authorize service.Eventually, either the negotiation succeeds or the client SA mustabandon the attempt. The negotiation succeeds when the client SAsatisfies the original SGP by disclosing sufficient unlockedcredentials. At the same time, the client SA repeats the originalservice request (305), this time with sufficient credentials attached(304) to authorize service.

[0046] 4.2. Trust Negotiation Model

[0047] In this section we introduce the abstract model used in Section 5to define and analyze two negotiation strategies. The abstract modelformalizes a trust negotiation as a sequence of credential disclosuresthat alternate between the two participants, optionally augmented by asequence of credential requests that serve to guide the disclosures.

[0048] The participants in a trust negotiation are the client andserver. Each owns a finite set of credentials, which we denote byClientCreds and ServerCreds, respectively. Access to each credential cin ClientCreds or ServerCreds is governed by a policy, denotedgov_(client)(c) or gov_(server)(c), respectively. If a credentialexpression, ψ, is satisfied by a set of credentials C, we write sat(C,ψ). Credential expressions are required to be monotonic; that is, if C

C′, then sat(C, ψ) implies sat(C′, ψ). We write ψ≡=ψ′ if for allcredential sets C, sat(C, ψ) iff sat(C, ψ′). We do not specify alanguage of credential expresions here, though an example language isoutlined in Section 6. However, in Section 5.2, we do require thelanguage to satisfy the following expressivity requirement: If Creds isany finite set of credentials and C is any set of subjects of Creds,then there exists ψ such that for all C

Creds, sat(C, ψ) iff C ∈ C.

[0049] If C

ClientCreds and c∈ ServerCreds such that sat(C, gov_(server)(C)), or ifC

ServerCreds and c∈ClientCreds such that sat(C, gov_(client)(c)), wewrite unlocked(c, C). If unlocked(c, Ø), c is unprotected. Lifting tosets of credentials, C′, we write unlocked(C′, C) if unlocked(c, C)holds for each c∈C′.

[0050] A trust negotiation is given by a sequence of credentialdisclosures, {C_(i)}_(i) _(^(∈)) _([0,m])=C₀, C₁, . . . C_(m), for somenatural number m. (Throughout we use the notation [i, j] to denote theinteger interval from i to j, inclusive). Each disclosure corresponds toa method. C₀ models a disclosure by the client to the server. Thedisclosures then alternate between the two subjects. That is, defining{AltCreds_(i)}_(0≦1) by AltCreds_(i)=ClientCreds for even i andAltCreds_(i)=ServerCreds for odd i, we require C_(i)

AltCreds_(i) for all i, 0≦i ≦m.

[0051] The credentials in each disclosure are required to be unlocked bycredentials from the other negotiation participant in the previousdisclosure, which means that the first disclosure consists entirely ofcredentials that are unprotected. That is, we have unlocked(C₀, Ø) andunlocked(C_(C1+1), C_(i)) for all ≦i≦m. Any disclosure can be empty,provided the subsequent disclosure consists of unprotected credentials.

[0052] Both client and server may set trust requirements that a trustnegotiation may or may not succeed in establishing. Trust requirementsare formalized by credential expressions. The trust requirement ofprimary concern herein is the server's policy governing access to aservice: the SGP. However, a client might also set a trust requirementthat it enforces before doing business with a server. In negotiationstrategies where trust requirements provide a goal that focuses thecredential exchange, we call the trust requirements trust targets.

[0053] A trust negotiation satisfies a server-set trust requirement, ψ,if some client disclosure satisfies ψ, i.e., if sat(C_(j), ψ) for someeven j∈[0,m]. A trust negotiation satisfies a client-set trustrequirement, ψ, if some server disclosure satisfies ψ, i.e., ifsat(C_(j), ψ) for some odd j∈[0, m]. In either case, we say that{C_(i)}_(i) _(^(∈)) _([0,m]) satisfies ψ.

[0054] In some trust negotiation strategies introduced in Section 5,disclosures are guided by credential requests that are also exchanged bythe negotiation participants. Credential requests are formalized by asequence of credential expressions that accompanies the trustnegotiation and that has the same length as the sequence of disclosures.For a given trust negotiation, {C_(i)}_(i) _(^(∈)) _([0,m]) anaccompanying sequence of credential requests has the form {ψ_(i)}_(i)_(^(∈)) _([0,m]).

[0055] 5. Negotiation Strategy

[0056] In our trust negotiation architecture, the negotiation strategydetermines the search for a successful negotiation. The strategycontrols which credentials are disclosed, when they are disclosed, andwhich credentials are requested from the other subject to unlock localcredentials. Successful trust negotiation is not always possible. Onesubject or the other may not possess needed credentials, or subjects maygovern their credentials by policies that, together, impose cyclicdependencies. The strategy determines when the negotiationinstigator-the client in our architecture-gives up on a negotiation.

[0057] Some desirable properties of negotiation strategies are asfollows. A strategy should lead to a successful negotiation whenever oneexists; that is, it should be complete. It should terminate with failurewhen success is impossible. Ideally, it should enforce a need-to-knowpolicy, avoiding disclosing credentials that are not needed for thenegotiation to succeed and disclosing no credentials when thenegotiation fails. Finally, a strategy should be efficient, giving areasonable bound on the number of messages that must flow during thenegotiation. We analyze the extent to which these properties aresatisfied by using the abstract model defined in Section 4.2.

[0058] Within the context of the abstract model, we identify eachnegotiation strategy with a set of trust negotiations. This high levelof abstraction focuses our attention on the essential relationshipsbetween CAPs and the disclosures and requests that flow between clientand server SAs in each strategy. Some practical matters are notformalized: what is an effective procedure for constructing counterrequests; how to truncate negotiations early when success is impossible;and when do service requests flow? These matters are discussedinformally.

[0059] This section defines and analyzes two negotiation strategies. Thefirst, our eager strategy, is complete and efficient. However, it doesnot enforce a need-to-know policy, and discloses many credentialsneedlessly. The second, our parsimonious strategy, begins by exchangingcredential requests, but no credentials, exploring (backwards) allpossible sequences of disclosures that lead to the satisfaction of agiven trust target. The sequence of requests reaches a request that canbe satisfied by unprotected credentials at exactly the point where thebackwards exploration of fruitful disclosure sequences reaches thebeginning of the shortest sequences. Starting at that point, thestrategy performs a credential exchange that is minimal in length andthat makes a locally minimal disclosure at each step. Unfortunately,because of limits on the degree of cooperation between the twoparticipants in this strategy, a globally minimal disclosure is notguaranteed.

[0060] 5.1. An Eager Strategy

[0061] In the eager strategy, two security agents take turns sendingevery credential they have that is currently unlocked. As credentialsare exchanged, more credentials become unlocked. The client terminates anegotiation when it receives a set of credentials from the server thatit has already received (no new credentials) or the set it receivesunlocks no new client credentials. This strategy, as formalized here,does not focus on a particular trust target, but simply expedites amaximal credential exchange.

[0062] Definition (Eager Negotiation). A trust negotiation, {C_(i)}_(i)_(^(∈)) _([0,m]), is an eager negotiation if,

[0063] 1. for all 0≦i≦m, C_(i) is the maximal set such thatunlocked(C₀,Ø) and unlocked(C_(i+1), C_(i)), and,

[0064] 2. for all 0≦i≦m−3, C_(i)≠ C_(i+2), and,

[0065] 3. if m is even, C_(m−2)≠ C_(m).

[0066] Since it is the client that detects termination, the lastdisclosure from the server may repeat the server's prior disclosure. Inthe following discussion, ClientCreds, ServerCreds, gov_(client), andgov_(server), are fixed but arbitrary.

[0067] The first therorem gives a tight bound on the number of messagesin an eager negotiation: the number of credential disclosures is boundedby the number of credentials each participant has. A tighter bound isthe length of the longest chain of dependencies among credentialspossessed by the two participants.

[0068] Theorem 1 (Efficiency of eager negotiation): The length, m+1, ofany eager negotiation, {C_(i)}_(i) _(^(∈)) _([0,m]), is at most2×min(|ClientCreds|+1, |ServerCreds|+1).

[0069] Proof: A simple induction on i shows that the sequence of clientdisclosures (even indices) and the sequence of server disclosures (oddindices) are both strictly increasing (with respect to

), except possibly for the last server disclosure. In general, |S|+1 isthe maximum length of a strictly increasing sequence of subsets of afinite set S. If the first server disclosure is empty (C₁=Ø), then nonew client credentials will be unlocked, so the negotiation terminateswith length two. Thus, the length of each of these sequences is boundedby one plus the size of the set from which the disclosures are drawn.

[0070] Theorem 2 (Uniqueness of eager negotiation): There is a uniquemaximal length eager negotiation.

[0071] Proof: If we fix two maximal length eager negotiations, a simpleinduction on the indices shows that corresponding disclosures areidentical in the two negotiations.

[0072] Theorem 3 (Completeness of eager negotiation): For any credentialexpression, ψ, if there exists any trust negotiation satisfying ψ, thenthe maximal length eager negotiation satisfies

[0073] Proof: Consider any trust negotiation {C_(i)}_(l) _(^(∈))_([0,m]) satisfying ψ. Let {C′_(i)}_(i) _(^(∈)) _([0,m′]) be the uniquemaximal length eager negotiation.

[0074] Without loss of generality, we assume that the trust requirementψ, is server-set and we fix an even n ∈ [0, m] such that sat(C_(n), ψ)

[0075] If m′<n, we extend the sequence {C′_(i)}_(i) _(^(∈)) _([0,m′]) to{C′_(i)}_(i) _(^(∈)) _([0,n]) by defining C′_(i) to be the maximal setsuch that unlocked(C′_(i), C′_(i−l)) for m′<i≦n. This makes the extendedsequence alternate the last two values of the original sequence. Moreprecisely, C′_(i)=C′_(m) for all i∈[m′+2,n] with the same parity (evenor odd) as m′ and C′_(i)=C′_(m−1) for all i∈[m′+1,n] with the sameparity as m′−1.

[0076] We now use induction on i to show that C_(i)

C′_(i) for all i∈[0,n]. It will then follow from sat(C′_(n), ψ) and themonotonicity of sat that sat(C′_(n), ψ). Since the extension of{C′_(i)}_(i) _(^(∈)) _([0,m′]) to {C′_(i)}_(i) _(^(∈)) _([0,n]) justrepeats C_(m′−1) and C_(m′), this means {C′_(i)}_(l) _(^(∈)) _([0,m′])satisfies ψ, completing the proof.

[0077] Basis: By definition of trust negotiations, an initial disclosureconsists entirely of client credentials that are unprotected. That is,C₀ satisfied unlocked(C₀,Ø). By definition of eager negotiation, aninitial disclosure is the maximal set of unprotected client credentials.That is, C′₀, is the maximal set of client credentials such thatunlocked(C′₀,Ø). Thus, C₀

C′₀.

[0078] Step: Assume C_(i)

C′_(i). C_(i+1) satisfies unlocked(C_(i+1), C_(i)) and C′_(i+l) is themaximal set such that unlocked(C′_(i+1), C′_(i)). By monotonicity ofsat, sat(C_(i), gov(c)) implies sat(C′_(i), gov(c)) for each c∈C_(i+1).It follows that unlocked (C_(i+1), C′_(l)), and hence that C_(i+1)

C′_(i+1), as required to complete the proof.

[0079] Because they exchange credentials as fast as permitted by theirCAPs, eager negotiations reach the required level of trust afterexchanging a minimal number of messages.

[0080] Corollory 4 (Minimality of length of eager negotiation): For anycredential expression, ψ, if there exists any trust negotiationsatisfying ψ, then there exists an eager negotiation of equal or lesserlength satisfying ψ.

[0081] Proof: The minimality of length of eager negotiation followsdirectly from the proof of completeness of eager negotiation (Theorem 3)by fixing the least even n ∈[0, m] such that sat(C_(n), ψ) and showingthat sat(C′_(n) ψ).

[0082] Several variants of the eager strategy defined above may bedeployed in practice. As suggested by Corollary 4, for a given targetcredential expression, such as the SGP, it is not always necessary toperform an entire eager negotiation. The simplest way to achieve earlytermination on success has the client repeat its service request witheach of its disclosures. When the server receives a message containingboth a service request and client credentials, it returns either theservice if it is authorized or, otherwise, those of its credentials thatare now unlocked. Eventually, either the service is granted, or no newcredentials are disclosed and the client terminates the negotiation withfailure.

[0083] Another variant has the server return the SGP as a credentialrequest, ψ₁. In this variant, one may modify slightly the definition ofthe eager strategy above, making the first two disclosures empty,thereby allowing the service request and SGP to flow before anycredentials. After those first two messages, if the client hasunprotected credentials that satisfy the SGP, it discloses them with arepeat of the service request, and obtains the service. If the clientdoes not have credentials that satisfy the SGP, it terminates thenegotiation without sending any credentials. If the client hassatisfactory but locked credentials, it continues the negotiation asabove by sending its unlocked credentials and requesting the server'sunlocked credentials, now checking at each round whether the SGP can besatisfied yet with its unlocked credentials. Eventually, either the SGPcan be satisfied—in which case the client resends the service requestalong with the required credentials—or the client determines thatnegotiation has failed.

[0084] The strengths of the eager strategy are its simplicity and thefact that no information about credentials possessed is disclosed unlessthe CAP of the credential in question is satisfied. Its weakness is thatit discloses credentials without regard to their relevance to thepresent negotiation: there is no provision for disclosing on aneed-to-know basis.

[0085] 5.2 A Parsimonious Strategy

[0086] Eager negotiations begin exchanging credentials essentiallyimmediately. They make little or no use of credential requests; althoughone of the variants presented above does call for the SGP to flow as acredential request, even there, until the SGP can be satisfied byunlocked client credentials, all unlocked credentials are exchangedwithout regard for any credential request. This section defines andanalyzes the parsimonious strategy, which differs from the eagerstrategy in these respects. An intuitive explanation precedes the formaldefinition. The numbering in this intuitive explanation corresponds tothe numbering in the formal definition below.

[0087] 1. Requests are exchanged to guide the negotiation towardsatisfying a particular trust target, ψ. In general, this trust targetcould be a SGP or a trust requirement set by the client. To simplify thepresentation, we assume the trust target is a SGP. The specification andensuing results can easily be generalized to cover the case of a trusttarget set by the client as well. Under this assumption, the firstcredential request from the server, ψ₁ is the trust target (i.e., theSGP) (The content of ψ₀ is irrelevant and undefined).

[0088] 2. When and if a request is sent that can be satisfied byunprotected (and therefore unlocked) credentials, the negotiationreaches the point of confidence. Corollary 8 and Theorem 9 belowtogether show that when this occurs, the negotiation is bound tosucceed.

[0089] 3. Initial credential disclosures are empty in each stage up toand including the point of confidence. If the point of confidence isnever reached, the negotiation terminates without disclosing anycredentials.

[0090] 4. Prior to the point of confidence, each successive credentialrequest is derived from its predecessor in a manner that makessatisfying that request a necessary and sufficient condition for adisclosure to unlock credentials that satisfy the predecessor.

[0091] 5. After the point of confidence is reached, the client resendsits prior requests, going through them backwards, at the same timedisclosing appropriate credentials to unlock solutions to thoserequests.

[0092] 6. As mentioned above in point 2, when and if a request is sentthat can be satisfied by a set of unprotected credentials, a minimalsuch set is disclosed in the next stage. Each successive step alsodiscloses a minimal credential set that satisfies a credential request,working backwards through the requests that were issued prior toreaching the point of confidence. The client, which drives thenegotiation, will have recorded each of the requests that has flowed. Itrefers to requests it received from the server when selecting its owncredential disclosures; it resends the requests it sent to the server,as outlined in point 5 above. Each disclosure unlocks the next, until adisclosure satisfying the original trust target is unlocked.

[0093] Definition (Parsimonious Negotiation): Let the target credentialexpression be ψ. To be a parsimonious negotiation with respect to thetrust target, ψ, a trust negotiation, {C_(i)}_(i) _(^(∈)) _([0,m]), mustbe accompanied by a sequence of credential requests, {ψ}_(i) _(^(∈))_([0,m]), and must satisfy the following six requirements:

[0094] ψ=ψ₁.

[0095] 2. If there exists a j∈[1,m], and a C

AltCreds_(j+1), such that sat(C, ψ_(j)) and unlocked(C,Ø), then, lettingk be the least such j, we say that the negotiation reaches the point ofconfidence at stage k. Otherwise, we let k=m.

[0096] 3. For all i, 1≦i≦k, C_(l)=Ø

[0097] 4. For all i, 1≦i≦k, ψ_(i) and ψ_(i+1) have the followingrelationship:

[0098] For all C

AltCreds_(i+2), we have sat(C, ψ_(i+1)) iff there exists a C′

AltCreds_(i+1), such that sat(C′, ψ_(i)) and unlocked(C′, C) 5. Afterreaching the point of confidence, prior client requests (which have evenindexes) are replayed. If k is even, we require ψ_(k+j)=ψ_(k−j) for evenj, 2≦j<m−k (if any). If k is odd, we require ψ_(k+j)=ψ_(k−j) for odd j,1≦j<m−k (if any).

[0099] 6. If the negotiation reaches the point of confidence at stage k,we require that for all j, 0≦j<m−k, (if any) C_(k+j+1) is a minimal(under

) subset of AltCreds_(k+j+1) satisfying sat(C_(k+j+), ψ_(k−j)) (and, asfor any trust negotiation, unlocked(C_(k+j+1), C_(k+j)) (recall thatC_(k)=Ø)).

[0100] In Requirement 4, for any ψ_(i), we know that ψ_(i+) exists bythe expressivity requirement on credential expression languages (seeSection 4.2). Since each parsimonious negotiation, {C_(i)}_(i) _(^(∈))_([0,m]), has an associated sequence of credential requests, {ψ_(i)}_(i)_(^(∈)) _([0,m],) we often refer to the parsimonious negotiation as thepair <{C_(i)}_(i) _(^(∈)) _([0,m],), {ψ_(l)}_(i) _(^(∈)) _([0,m)]>. Inthe following discussion, ClientCreds, ServerCreds, gov_(client), andgov_(server) are fixed but arbitrary.

[0101] Theorem 5 (Determinacy of Requests in Parsimonious Negotiation):Given two parsimonious negotiations, <{C_(i)}_(i) _(^(∈)) _([0,m],){ψ_(l)}_(i) _(^(∈)) _([0,m])> and <{C′_(i)}_(i) _(^(∈)) _([0,n]),{ψ′_(i)}_(i) _(^(∈)) _([0,n])> with equivalent trust targets, ψ₁≡ψ′₁, wehave ψ_(l)≡ψ_(l) for all i, 1≦i≦k, where k is either the stage where oneof the negotiations reaches the point of confidence, m, or n, whicheveris least.

[0102] Proof: The proof is a straightforward induction on i using thedefinition of ═ and Requirement 4 of the definition of parsimoniousnegotiation.

[0103] The next theorem gives a tight bound on the number of possiblemessages that must flow before the parsimonious strategy determineswhether the negotiation will succeed.

[0104] Theorem 6 (When success is possible, parsimonious negotiationsefficiently reach the point of confidence): Given any credentialexpression ψ, if there exists a trust negotiation that satisfies ψ, thenwe have the following: 1. There exists a natural numberk≦2×min(|ClientCreds|+1, |Servercreds|+1) such that every parsimoniousnegotiation <{C_(i)}_(i) _(^(∈)) _([0,m],) {ψ_(i)}_(i) _(^(∈)) _([0,m])>with k>m and trust target ψ reaches the point of confidence at stage k;and

[0105] 2. Every parsimonious negotiation <{C_(i)}_(i) _(^(∈)) _([0,m]),{ψ_(i)}_(i) _(^(∈)) _([0,m])> with trust target ψ that has not reachedthe point of confidence (i.e., m >k) can be extended to a parsimoniousnegotiation that reaches the point of confidence at stage k.

[0106] Proof: Assume there exists a trust negotiation satisfying ψ. Webegin by showing the first part of the Theorem. By Theorem 3 it followsthat there exists an eager negotiation that satisfies ψ. Let it be givenby {C′_(i)}_(i) _(^(∈)) _([0,m′].) As discussed in the definition of theparsimonious strategy, we have assumed for simplicity that the trusttarget is an SGP. Let n′∈[0, m′] be the least even index such thatsat(C′_(n′), ψ).

[0107] Consider any parsimonious negotiation, <{C_(i)}_(i) _(^(∈))_([0,m],) {ψ_(i)}_(i) _(^(∈)) _([0,m])> with n′≦m. We use induction on ito prove that, for all i ∈[0, n′−2],

[0108] 1. sat(C′_(n′−i), ψ_(1+i)), and

[0109] 2. for all C

AltCreds_(n′−i) such that sat(C, ψ_(l+i)) unlocked(C, Ø) does not hold.

[0110] Note that when n′=0, the result is trivial (there is nothing toprove). So we may assume that 2≦n′.

[0111] Basis: sat(C′_(n′), ψ₁) follows from the assumption thatsat(C′_(n′), ψ) and Requirement 1 of the definition of parsimoniousnegotiation (“PN Req. 1”), viz. ψ₁=ψ. For the second proof obligation,suppose for contradiction that there exists a C

AltCreds_(n′)=ClientCreds such that sat(C, ψ₁) and unlocked(C, Ø). Thensat(C′₀, ψ), by definition of eager strategy and by monotonicity of sat,so by choice of n′, n′=0, which gives the desired contradiction with theassumption that 2≦n′.

[0112] Step: Fix any i∈[0, n′−3] and assume that

[0113] 3. sat(C′_(n′−i), ψ_(1+i)), and

[0114] 4. for all j∈[0, i] and all C

AltCreds_(n′−j) such that sat(C, ψ_(1+j)) unlocked(C, Ø) does not hold.

[0115] We show that

[0116] 5. sat(C′_(n′−(i+l)), ψ_(1+(i+l))), and

[0117] 6. for all C

AltCreds_(n′−(i+1)) such that sat(C, ψ_(l+(i+1))), unlocked(C, Ø) doesnot hold.

[0118] From induction assumption (4) and PN Req. 2, it follows that thek introduced in PN Req. 2 has i+1<k. Therefore, by PN Req. 4, ψ_(i+1)and ψi+2 bear the following relationship:

[0119] For all C such that C

AltCreds_(i+3), we have sat(C, ψ_(i+2)) if and only if there exists a C′

AltCreds_(i+2) such that sat(C′, ψ_(i+l)) and unlocked(C′, C).

[0120] Taking C=C′_(n′−(i+1)), we have C

AltCreds_(i+3) because n′−(i+1) and i+3 have the same parity. We showthat C′=C′_(n′−i) has the required properties to give us inductionobligation (5). First, C′_(n′−i)

AltCreds_(i+2) holds because n′−i and i+2 have the same parity. Second,sat(C′_(n−i), ψ_(i+)1) holds by induction assumption (3). Third,unlocked(C′_(n′−i), C′_(n′−(i+1))) is a requirement of the eagerstrategy.

[0121] We now complete the step by proving induction obligation (6).Suppose for contradiction that there is a C

AltCreds_(n′−(i+1)) such that sat(C, ψ_(1+(i+1))) and unlocked(C, Ø). Byassumption on i, i+1≦n′−2. We obtain the desired contradiction byproving that sat(C′_(i+1), ψ), and therefore that n′ is not the leasteven index satisfying sat(C′_(n′), ψ). For this it is sufficient to showthat for each j∈[0, i+1], sat(C′_(j), ψ_(i+2−j)) which we nowdemonstrate by using induction on j.

[0122] Basis: sat(C′ 0, ψ_(i+2)) follows from the assumption that sat(C,ψ_(i+2)) the observation that unlocked(C, Ø) implies C

C′₀, and the monotonicity of sat.

[0123] Step: Assume j∈[0, i] and

[0124] 7. sat(C′_(j), ψ_(i+2−j)).

[0125] We show

[0126] 8. sat(C′_(j+1), ψ_(i+2−(j+1))).

[0127] As noted at the top of the outer induction step, the k introducedin PN Req. 2 has i+1<k. It follows that i+2−(j+1)<k. So PN Req. 4 givesus:

[0128] For all C such that C

AltCreds_(i+2−j+1), sat(C, ψ_(i+2−j)) holds if and only if there existsa C′

AltCreds_(i+2−j) with sat(C′, ψ_(i+2−(j+1))) and unlocked(C′, C).

[0129] Taking C=C′_(j), we obtain the left-hand side from the inductionassumption (7). The right-hand side therefore also holds unlocked(C′,C′_(j)) and the eager negotiation requirement that C′_(j+1) be themaximal set satisfying unlocked(C′_(j+1), C′_(j)) give us C′

C′_(j+1). So the obligation (8) follows by monotonicity of sat. Thisconcludes both inductions.

[0130] We proceed by analyzing propositions (1) and (2) for the nextvalues of i, viz. i=n′−1 and i=n′. By using the same argument as we usedabove to prove induction obligation (5), we obtain sat(C′₁, ψ_(n′)).There are now two cases. Either there exists a C

AltCreds₁ such that sat(C, ψ_(n′)) and unlocked(C, Ø), or there doesnot. In the former case, taking k=n′, the parsimonious negotiationreaches the point of confidence at stage k, as desired. In the lattercase, we take k=n′+1. When n′=m, there is nothing to prove because thehypothesis of the theorem, k≦m, is not satisfied. When n′+1≦m, we againuse the argument used above to prove induction obligation (5), therebyshowing sat(C′₀, ψ_(n′+1)). In this case, the parsimonious negotiationreaches the point of confidence at stage k because unlocked(C′₀, Ø)holds by definition of the eager strategy.

[0131] For the bound on k, observe that k≦m′≦2×min(|ClientCreds|+1,|Servercreds|+1), the last inequality being Theorem 1.

[0132] Now we show the second part of the theorem. Suppose <{C_(i)}_(i)_(^(∈)) _([0,m],) {ψ_(i)}_(i) _(^(∈)) _([0,m])> has m<k. Recall that forany i∈[0,k], C_(l)=Ø by PN Req. 3. So, to extend the negotiation, weneed only find ψ_(m+1) satisfying PN Req. 4. Such a ψ_(m+1) isguaranteed to exist by the expressivity requirement on the credentialexpression language introduced in Section 4.2. Part one of the currenttheorem shows that the point of confidence is not reached until stage k.Consequently, this process of extending any shorter parsimoniousnegotiation can be applied inductively to obtain a parsimoniousnegotiation that reaches the point of confidence.

[0133] The search for a successful parsimonious negotiation is trivialbecause once the point of confidence is reached, every partialnegotiation can be extended to a successful one and every way ofextending it is successful.

[0134] Definition (Stuck Parsimonious Negotiation): Let <{C_(i)}_(i)_(^(∈)) _([0,m]), {ψ_(l)}_(l) _(^(∈)) _([0,m])> be a parsimoniousnegotiation with respect to some trust target ψ. <{C_(i)}_(i) _(^(∈))_([0,m]), {ψi}_(i) _(^(∈)) _([0,m])> is stuck if it reaches the point ofconfidence at some stage k, m<2k, and there is no C′

AltCreds_(m+1) with sat(C′, ψ_(2k−m)) and unlocked(C′, C_(m)).

[0135] Theorem 7 (Parsimonious negotiations are not stuck): Noparsimonious negotiation is stuck.

[0136] Proof: Consider any parsimonious negotiation, <{C_(i)}_(i)_(^(∈)) _([0,m]), {ψ_(i)}_(i) _(^(∈)) _([0,m])> with k≦m<2k. If k=m, thenegotiation is not stuck because by choice of k in PN Req. 2, thereexists C′

AltCreds_(k+1) with sat(C′, ψ_(k)) and unlocked(C′, Ø). (Note that by PNReq. 3, C_(k)=Ø).

[0137] We now consider k<m<2k. By taking j=m−k−1 in PN Req.sat(C_(k+(m−k−1)+1), ψ_(k−(m−k−1))), that is, sat(C_(m), ψ_(2k−m+1))).By PN Req. 4:

[0138] For all C

AltCreds_(2k−m+2), we have sat(C, ψ_(2k−m+1)) iff there exists a C′

AltCreds_(2k−m+1), such that sat(C′, ψ_(2k−m)) and unlocked(C′, C).

[0139] By definition of trust negotiation, C_(m)

AltCreds_(m=AltCreds) _(2k−m+2). So, taking C=C_(m), it follows thatthere must exist a C′

AltCreds_(2k−m+l), such that sat(C′, ψ_(2k−m)) and unlocked(C′, C_(m)).Since AltCreds_(m+l)=AltCreds_(2k−m+1), this completes the proof.

[0140] Corollary 8 (Parsimonious negotiations that reach the point ofconfidence can be extended): Every parsimonious negotiation that reachesthe point of confidence at some stage k can be extended to form aparsimonious negotiation of length 2k+1.

[0141] Proof: Follows by inductively applying Theorem 7 to show theexistence of a disclosure that can be used to extend the negotiation onestep.

[0142] Theorem 9 (Parsimonious negotiations that reach the point ofconfidence and are sufficiently long satisfy their trust targets): Everyparsimonious negotiation <{C_(i)}_(i)

_([0,m]), {ψ_(i)}_(i)

_([0,m])> that reaches the point of confidence at some stage k and hasm=2k satisfies its trust target.

[0143] Proof: By PN Req. 6, sat(C_(k+(m−k−l)+l), ψ_(k−(m−k−1))). Usingm=2k, we get sat(C_(2k), ψ₁). By PN Req. 1, ψ₁≡ψ, completing the proof.

[0144] Corollary 10 (Completeness and efficiency of parsimoniousnegotiation): Given any credential expression ψ, if there exists a trustnegotiation that satisfies ψ, then there exists a natural numberk≦2×min(|ClientCreds|, |ServerCreds|) such that every parsimoniousnegotiation with trust target ψ and length 2k+1 satisfiesψ. Moreover,every parsimonious negotiation with trust target ψ and length less than2k+1 can be extended to one with length 2k+1.

[0145] Proof: Follows from Theorems 6 and 9 and from Corollary 8.

[0146] Theorem 11 (Local minimality of disclosures in parsimoniousnegotiation): In a parsimonious negotiation, no credential is discloseduntil the point of confidence is reached, at which time successfulnegotiation is guaranteed. Then, each disclosure consists of a minimal(under

) set of credentials sufficient to unlock either the next credentialdisclosure or the desired service.

[0147] Proof: The first part is immediate from PN Req. 3, Corollary 8and Theorem 9. The second part follows from PN Reqs. 6, 4, and 1.

[0148] Any deployment of the parsimonious strategy should take advantageof the fact that, if a successful negotiation exists, the initialexchange of credential requests will encounter a request that can besatisfied by unprotected credentials within the first 2×|ClientCreds|requests. If such a request has not occurred, the negotiation should beterminated.

[0149] An issue that must be faced in deploying this strategy is theeffective derivation of credential requests that satisfy Requirement 4.In principle, these counter requests can be constructed, provided thecredential language is able to represent logical “and” and “or”. A“brute-force” approach constructs counter requests as follows. Assumethat

and

denote “and” and “or”, i.e., that for all C, we have sat(C,

{ψ₀, ψ₁, . . . ψ_(n)}) iff sat(C, ψ_(i)) for each i, 1≦i≦n and sat(C,

{ψ₀, ψ₁, . . . , ψ_(n)}) iff sat(C, ψ_(i)) for some i, 1≦i≦n. Counterrequests can be computed by the server from the incoming request byusing counter_(server)(ψ)=

{gov_(server)(C) | sat(C, ψ)}, where gov_(server)(C)=

{gov_(server)(c) | c

C}. Construction of the client's counter requests is analogous. Oneproblem with using this construction in practice is that it entailsconstructing the set {C | sat(C, ψ)}, which in general may be verylarge. It is a matter of future work to construct an efficient method ofderiving compact counter requests for the credential expression languagepresented in Section 6.

[0150] Example. We illustrate the parsimonious strategy by simplifyingseveral issues. We ignore the fact that credentials are submitted withsupporting credentials, and also the internal structure of credentials.We use very crude credential expression language that treats credentialsas propositional variables.

[0151] Let ClientCreds={a, b, c, d}, ServerCreds={x, y}, gov_(client)={a

Ø, b

Ø, c

x, d

y}, and gov_(server)={x

a

b, y

a

b}. In the exchanges, we use ⊥ to represent values that are notdetermined or used by the parsimonious negotiation. Recall that ψ₁represents the trust target—an SGP: ψ₀=⊥, ψ₁=(a

d)

(c

b), ψ₂=x

y, ψ₃=a

b, ψ₄=x

y, ψ₅=⊥, ψ₆=⊥, ψ₇=⊥; C₁=Ø, C₁=Ø, C₂=Ø, C₃=Ø, C₄={a}, C₅={x}, C₆={b,c},C₇=⊥. The total set of credentials disclosed by the client in thisnegotiation is not minimal, because the client could have disclosed b inC₄ instead of a. However, if the client had tried this, the serverchoice in C₅ could instead have been to disclose {y}, forcing the clientto disclose {a,d} in C₆, which again is not minimal. This exampleillustrates the difficulty of devising a negotiation strategy in whichthe two participants cooperate in exchanging a globally minimal set ofcredentials.

[0152] 5.3. Hybrid Strategies

[0153] This section sketches informally an approach to combining eagerand parsimonious strategies in an effort to use each with thecredentials for which it is better suited. CAPs can be made two-part,comprising not only a credential expression, but also a flag to selectbetween parsimonious and eager disclosure. A credential flagged foreager disclosure would be disclosed freely to all sites that presentcredentials that satisfy the credential-expression component of its CAP.One flagged “parsimonious” would be disclosed only as part of a locallyminimal exchange and successful negotiation. A hybrid strategy beginswith a phase that uses an eager strategy to attempt to negotiate usingonly credentials flagged for eager disclosure. If success is possibleusing just those credentials, the negotiation succeeds during the eagerphase. If not, phase two uses a parsimonious strategy to attempt toestablish trust by using all credentials. Phase two takes advantage ofcredentials exchanged during phase one. In a hybrid negotiation, theclient determines when phase one has completed unsuccessfully and phasetwo begins. The client indicates in each request to the server whichstrategy it is currently employing. 5.4 An Example Trust NegotiationFramework

[0154] An example Trust Negotiation Framework will now be described thataddresses the problem of establishing trust sufficient to allowdisclosure of the credentials that must be exchanged to authorizeapplication-level transactions. It supports assigning different accesspolicies to different credentials, and issuing counter requests thatcombine the access policies of credentials that solve the incomingrequest. It also supports constructing counter requests in a way thattakes advantage of the credentials already available. The frameworkconsists of an architecture for supporting fully automated trustnegotiation between client and server, together with a partialspecification of the behavior of the components of the architecture. Theframework leaves the functional specification of certain components upto a negotiation strategy, with respect to which the framework isparameterized. Having differing characteristics, different negotiationstrategies satisfy different priorities, such as minimizing credentialdisclosure and negotiating trust successfully whenever possible, asdiscussed in relation to the eager and parsimonious strategies in thepreceding section. One strategy characteristic is which credentials todisclose and when. A second is how to formulate a counter-request, ifany, when trust has not yet been established. A third is when to give upon a negotiation, without establishing trust. The framework presentednow can accommodate different negotiation strategies, dependent on thenegotiation priorities in a particular situation.

[0155] Each of the two negotiation participants is represented in trustnegotiations by a security agent (SA). The SA manages the disclosure oflocal-site credentials. In our framework, each locally-owned credentialis governed by an access policy, which has the same form as aservice-governing policy. The access policy identifies opposing-sitecredentials that would unlock dislosure of the local-site credential tothat opposing site.

[0156] Our framework assumes that servers are stateless, although itcould be adapted to take advantage of stateful servers. The clientinitiates the trust negotiation by making a service request. Uponreceiving a request for service, the server SA makes an appropriateauthorization decision based on a service-governing policy. When theclient SA is familiar with the service and its governing policy, it canattach appropriate credentials to the service request so that theservice will be authorized. The server SA determines whether the policygoverning the requested service is satisfied by such credentials if any.If the policy is satisfied, the service is authorized and the request isforwarded to the server which provides the service to the client. Thetrust negotiation has completed successfully. Otherwise, the server SAsends the service-governing policy to the client SA as a request forcredentials. The client SA can then select a combination of credentialsthat satisfies the policy, and attach those credentials to a repetitionof the original service request, which it previously stored for thispurpose.

[0157] Our framework enables each SA to decide automatically, based onpre-established credential access policies and without userintervention, which credentials to disclose. If the client SA cannotsatisfy the servers request for credentials by using credentials whoseaccess polices are unlocked, it introduces further stages to the trustnegotiation. These stages seek to build mutual trust through credentialexchange. In each stage, the active entity can respond to a request forcredentials by providing credentials, by formulating a counter-requestfor opposing-site credentials, or both. The client SA, being stateful,can also repeat a previous request for credentials that has not yet beensatisfied. By exchanging credentials and requests for credentials, thetwo entities endeavor to establish the trust required to authorizeservice. Eventually, either the client SA abandons the attempt tonegotiate trust, or the negotiation succeeds. The negotiation succeedswhen the client SA can satisfy the original service-governing policy byusing client credentials whose access policies are satisfied byavailable opposing site credentials. In this case, the client SA repeatsthe original service request with adequate credentials attached toauthorize service.

[0158] 5.5 Functional Specification of the Framework

[0159] The following is a functional specification of the framework. Thespecification of functions in the third group below,CounterToServiceGoverningPolicy CounterToServiceGoverningPolicy, andHandleServerResponseToCredRequest, are determined by the negotiationstrategy chosen to instantiate the framework.

[0160] The first three expression-evaluation utilities are used todetermine if credentials can be disclosed.

[0161] Satisfied (expression, credentials) determines whether acredential expression is satisfied by credentials in a given set. If so,it returns a solution. It returns the empty set if no solution exists.

[0162] Unlocked (localcredentials, remotecredentials) is used todetermine local credentials that can be disclosed. It takes a set oflocal credentials and a set of remote credentials and returns the subsetof the local credentials whose access control policies are satisfied bythe remote credentials.

[0163] Locked (localCredentials, remotecredentials) is similar toUnlocked, but returns the subset of the local credentials whose accesscontrol policies are not satisfied by the remote credentials.

[0164] The next five functions are called to end a negotiation stage.

[0165] ReturnServiceResultToClient (serviceRequest) is used by theserver SA when service is authorized. It invokes the desired service,which then returns the service result to the client.

[0166] ReturnServiceGoverningPolicyToClient (policy) is called by theserver SA to send a service-governing policy to the client SA.

[0167] ExitWithNegotiationFailure ( ) is called by the client SA when itdetermines that a negotiation has failed. The negotiation terminates andfailure is reported by the client SA to the client.

[0168] RepeatServiceRequest (clientCredentials) is invoked by the clientSA when the negotiation succeeds in unlocking a set of clientcredentials that satisfy the service governing policy. That set ispassed as the functions argument. The function attaches the set ofclient credentials to the repeated service request, which it sends tothe server SA.

[0169] SendCounterRequest (request, credentials) is called to send acounter request to the opposing site. It takes an outgoing request foropposing-site credentials and any local credentials to be disclosed.Although the behavior of this function is independent of the negotiationstrategy, the form of the request is not.

[0170] The next three functions are specified by the negotiationstrategy. They are parameters of the framework that must be instantiatedto obtain a complete system specification. Although all instances of theframework can use the same type of policy to govern services andcredentials, the form of counter requests is, like these functions,determined by the negotiation strategy.

[0171] CounterToServiceGoverningPolicy (policy, clientCredentials) isinvoked by the client SA when it receives a service governing policythat can be satisfied, but only by using some locked, sensitivecredentials. This function determines a counter request for servercredentials and sends it to the server SA. It may also send someunlocked client credentials.

[0172] HandleRequestForServerCredentials (clientRequest,clientCredentials, serverCredentials) is invoked by the server SA tohandle a request from the client SA for server credentials. It takes aclient request for server credentials, a set of submitted clientcredentials, and a set of server credentials. It determines and sends tothe client SA a counter request, credentials to disclose, both, orneither.

[0173] HandleServerResponseToCredRequest (serverRequest,serverCredentials, clientCredentials) is invoked by the client SA whenit gets a response to a request for server credentials. It takes aserver request for client credentials, a set of submitted servercredentials, either or both of which could be empty, and a set of clientcredentials. It determines whether the negotiation should be terminatedwith failure, has succeeded, or should be continued. If the negotiationhas succeeded, the function repeats the original service request withappropriate credentials attached. If the negotiation should becontinued, a request for credentials is sent to the server SA, possiblywith client credentials attached.

[0174] The first of the following two functions is invoked by the serverSA to handle an incoming request for service. The second is invoked bythe client SA when it receives a service governing policy.

[0175] HandleRequestForService (serviceRequest, clientCredentials),defined below, is invoked by the server SA to handle an incoming requestfor service. It takes the service request and any attached credentials.It returns the service result when access is granted and the servicegoverning policy when access is denied.

[0176] policy=LookupServiceGoverningPolicy (serviceRequest)

[0177] creds=Satisfied (policy, clientcredentials)

[0178] if (creds) ReturnServiceResultToClient (serviceRequest)

[0179] else ReturnServiceGoverningPolicyToClient (policy)

[0180] HandleServiceGoverningPolicy (policy, clientCredentials), definedbelow, is invoked by the client SA when it receives a service governingpolicy from the server SA in response to a service request. It repeatsthe service request if the service governing policy has a solutionconsisting entirely of unlocked client credentials. Otherwise, if thereis a solution that includes some locked, sensitive client credentials,the function sends the server SA a counter request for servercredentials to unlock them. If the service governing policy cannot besatisfied at all by the clients credentials, the negotiation has failed.

[0181] creds=Satisfied (policy, Unlocked (clientcredentials, Ø))

[0182] if (creds) RepeatServiceRequest (creds)

[0183] else if (Satisfied (policy, clientcredentials))

[0184] CounterToServiceGoverningPolicy (policy, clientCredentials)

[0185] else ExitWithNegotiationFailure( )

[0186] 6. Credential Expression Languages

[0187] Credential expressions could specify combinations of credentialsdirectly, for instance by representing credential requirements asBoolean combinations of specific credentials. However, by layeringlevels of abstraction, we aim to provide a basis for overcoming thecomplexity of authenticating strangers by using credentials obtained forother purposes. Deriving relevant properties from such credentialsrequires care and expertise. It is important to separate this task fromthat of defining access requirements for individual services andcredentials. For this reason, our credential expression languagecomprises two parts, separating authentication from authorization. Forauthentication, credentials are mapped to roles; for authorization,access requirements are expressed as combinations of roles. Both partsare needed to define the credential requirements of a given accesspolicy or credential request. Both parts must flow when a policy orcredential request is transmitted from one agent to another.

[0188] The language we present is incomplete and not a formallanguage-design proposal. However, two language features, introduced anddiscussed in this section, reflect important issues that should guidefurther work in policy languages for trust negotiation. First, roleattributes enhance expressiveness. Second, the monotonic relationshipbetween credentials and access is essential in any context where asubject can withhold disclosure of its own credentials.

[0189] This section presents our Role-based Authorization Language (RAL)used in the example negotiation presented in Section 7. An authorizationpolicy defined in RAL consists of a role-constraint expression, whichexpresses requirements for access to the service or credential that itgoverns. These requirements are expressed in terms of roles of thesubject seeking access. These roles are defined by an authenticationpolicy written in our Property-based Authentication Language (PAL),which is also presented in this section. A PAL authentication policyassigns a subject to roles based on subject properties derived fromcredentials owned by the subject and from the roles of the issuers ofthose credentials. This assignment is independent of the question of thesubject's access to the service. Thus, a PAL role is not a capability,but represents a derived property of the subject.

[0190] Section 6.1 introduces PAL, which maps credentials to roles.Section 6.2 then introduces RAL, which uses those roles to define accessrequirements. Section 6.3 discusses the significance and impact ofsupporting role attributes.

[0191] 6.1. Property-based Authentication Language

[0192] A PAL authentication policy defines one or more roles. A role isa property of subjects defined in terms of the credentials they possessand the attribute values of those credentials. The notion of assigningsubjects to roles based on credentials goes back to Bina et al. [1]. InSeamons et al. [15] policies are Prolog programs. However, with theexception of a few features, PAL is based on the Trust Policy Language(TPL) of Mass et al. [10]. TPL introduced two intertwined innovations,which we adopt: the role is TPL's sole procedural abstraction; TPLassigns a role not only to the submitting subject, but also to eachowner of one of the supporting credentials.

[0193] PAL's role attributes enhance TPL, as discussed in Section 6.3.PAL also differs from TPL in that roles are monotonic functions ofcredentials: disclosing more credentials cannot decrease the roles towhich a subject authenticates. This is a requirement in trustnegotiation because subjects have control over the credentials theydisclose, but not the credentials they obtain.

[0194] For presentation purposes, we give PAL a concise notation derivedfrom syntax of constraint logic programming languages. A PAL role is auser-defined predicate over the public keys of subjects. Role attributestake the form of additional parameters. A PAL authorization policyconsists of a set of rules, each of which has the following form:

[0195] role(Attributes, . . . )← CredentialVar:credentialType, . . . ,

[0196] role₁(credentialVar.issuer, Attributes₁), . . . ,

[0197] credentialConstraints,

[0198] The head of the rule, to the left of the arrow, consists of asingle role, applied to an implicit subject key and to zero or moreexplicit role attributes, illustrated here by Attributes. Together, therules with the same role in their head define that role. The body of therule comprises the portion of the rule to the right of the arrow. One ormore credential variables are introduced, each by a variable typedeclaration, as illustrated by CredentialVar:credentialType. Theattributes of a credential are denoted with the syntaxCredentialVar.attribute. Credential variables and role attributes havenames that start with capital letters. Roles, credential types, andcredential attributes have names that start with lowercase letters.

[0199] Within a given rule, the subject being authenticated owns eachcredential denoted by a credential variable in that rule. The rulestates that the subject can authenticate to the role role with roleattributes Attributes if the subject owns a combination of credentialsof the designated types such that each of the rule's requirements holds.These requirements are of two kinds. The first requires that the issuerof a credential belongs to a given role. Such an issuer-role constraintis an application of a role to a credential-issuer key and roleattribute variables, and is illustrated by rolel(CredentialVar.issuer,attributes1). Note that the subject key (CredentialVar.issuer) isidentified explicitly in role applications that appear in a rule body.The issuer attribute of each credential variable must appear in at leastone issuer-role constraint. The second kind of requirement is a generalconstraint on the attributes of the credentials and roles appearing inthe rule. These are typically relational expressions, using operatorssuch as =, g, and [. Although not specified herein, user definedfunctions and operators may also be used. In addition to imposingrequirements on the credentials denoted by the credential variables,general constraints serve to define the attributes of the role in therule head. TABLE 2 1) hasCredit(Amount)← LetterOfCredit : credit,creditor(LetterOfCredit.issuer),Amount=LetterOfCredit.amount. 2)creditor( )← Creditor : creditor, self(Creditor.issuer). 3) knownClient()← Ref : reference, self(Ref.issuer), Ref.relationship=“shippingclient”. 4) knownClient( )← Ref1 : reference, Ref2 : reference,Ref1.issuer ≠ Ref2.issuer, shipper(Ref1.issuer), shipper(Ref2.issuer),Ref1.relationship=“shippingclient”, Ref2.relationship=“shipping client”.5) shipper( )← Ref : reference, self(Ref.issuer),Ref.relationship=“shipper”. 6) shipper( )← Ref1: reference, Ref2 :reference, Ref1.issuer ≠ Ref2.issuer, knownClient(Ref1.issuer),knownClient(Ref2.issuer), Ref1.relationship=“shipper”,Ref2.relationship=“shipper”.

[0200] Table 2 shows six PAL rules. The first rule defines one way asubject can be shown to be in the hasCredit role. If the fullauthentication policy contained other rules that defined hasCredit,those rules would state other ways to authenticate to the role. The rulehere states that a subject is in the hasCredit role if it owns a creditcredential issued by a subject in the creditor role. The rule alsostates that role attribute, Amount, is defined by credential attribute,amount.

[0201] To be satisfied, the rule must be evaluated in the presence ofthe credit credential mentioned above, as well as credentials, owned bythe credit credentials issuer, that satisfy a rule defining the creditorrole. The second rule shown in Table 2 is such a rule. It states that asubject is in the creditor role if it owns a creditor credential issuedby a member of the self role. The self role is unlike other roles. It ispredefined and its sole member is the owner of the policy, referred toas self. A credential issued by the policy owner is a self-signedcredential [12]. Unlike other credentials, self-signed credentials arepart of an authentication policy; they define the valid roots of allcredential chains. A chain of credentials that supports membership inthe hasCredit($10,000) role is shown in Table 3. This illustrates achain that proves subject A is in the creditor role and subject B is inthe hasCredit($10,000) role, as those roles are defined in Table 2.TABLE 3 type = creditor → type = Credit issuer = SelfKey issuer =subjectAKey owner = subjectAKey owner = subjectBKey amount = $10,000Credential 1 Credential 2

[0202] By making use of the TPL notion of role as a proceduralabstraction mechanism, an authorization policy can trace chains ofunbounded length [12]. Rules 3 through 6 in Table 2 define two roles,knownClient and shipper. A subject is in the knownClient or shipper roleif it has a corresponding self-signed reference credential from thepolicy owner. A subject is also in the knownClient role if it has areference from two shipper members. Similarly, a subject is also in theshipper role if it has a reference from two knownClient members.

[0203] To summarize, an authentication policy has three parts: a set ofrules, a set of self-signed credentials, and a set of user definedfunctions. Herein we generally exhibit only the rules. However, in anymobile policy, all three parts must flow.

[0204] 6.2. Role-based Authorization Language This section introducesthe Role-based Authorization Language (RAL). A RAL authorization policycomprises a role-constraint expression, together with a PALauthentication policy defining each role used therein. A role-constraintexpression is a logical formula consisting of role applications andattribute constraints combined with the logical connectives AND and OR.(These connectives give exactly the monotonic formulas.) A roleapplication consists of a role name applied to a subject (in theexample, just one of the reserved words Client or Server) and roleattribute variables. Attribute constraints are arbitrary constraints onthe role attributes appearing in the rule. An authorization policy thatgoverns a service may also use service parameter names in theseconstraints. As in PAL, user defined functions may be used.

[0205] Example. The following authorization policy could govern arequest for a service that schedules shipping. The parameters of therequest are: PickupLocation, Destination, and Tons.

[0206] hasCredit(Client, Amount) AND

[0207] Amount≧Tons×costPerTon(PickupLocation, Destination)

[0208] This policy requires that the client be in the hasCredit rolewith the Amount attribute value at least sufficient to pay the cost ofthe desired shipping. The function costPerTon is user defined.

[0209] When an authorization policy is combined with an authenticationpolicy that defines all the roles it uses, the two together define a setof solutions. Each solution is a minimal set of credentials that provesthat the subject in question (client or server) belongs to the requiredroles with the required attributes.

[0210] 6.3. Role Attributes

[0211] The association between attributes and roles enables the policywriter to make credential attributes, exported as role attributes,available in authorization policies. This enables authorization todepend on attributes-such as credit line, rating, or age-without theinconvenience of defining special purpose roles that impose theconstraints within the authentication policy.

[0212] Role attributes also have at least two other advantages in thecontext of TPL-style role definitions. First, by exporting credentialattributes, they enable attributes of different credentials in a chainto be compared. For instance, they could be used to compare attributesof a credential owner with attributes of the credential's issuer.Second, role attributes can be used to keep track of and to bound thelength of a credential chain. Consider the shipper role defined in Table2. While it is very convenient to let shippers and shipping clientsvouch for each other, as the number of subjects in a chain goes up, thepolicy writer's confidence in the last subject's role may go down. Anattribute, ChainLength, can be added to each of shipper and knownClient.By initializing it to zero in the rules that use self-signedcredentials, and incrementing it in each of the (mutually) recursiverules, the length can be computed. An authorization policy can theneasily impose an upper bound on the length of acceptable chains.

[0213] 7. Example Negotiations

[0214] This section presents two example trust negotiations based on theeager and parsimonious strategies. In the examples, a negotiation isundertaken to authorize on-line scheduling of shipping services by asmall, fictitious widget manufacturer, Acme Widget. The negotiationsuccessfully establishes the trust required to authorize the servicerequest and schedule shipping.

[0215] Table 2 and Table 4 present the role definitions used by theauthentication portions of the SGP and CAPs, as well as the requests forcredentials that may flow during the negotiation. To save space, we listeach rule only once, although it may be used in several places invarious policies and credential requests.

[0216] Although not shown, the authentication policies include necessaryself-signed credentials. In particular, the server's authenticationpolicies that define creditor also include a self-signed creditorcredential owned by Mattress Bank. Similarly, the client'sauthentication policies that define knownClient also include twoself-signed reference credentials, one owned by manufacturer 1 and oneby manufacturer 2, both with relationship=“shipping client”. TABLE 4 19)reputation(Rating)← Membership : businessOrgMember,businessOrganization(Membership.issuer),Rating=Membership.rating. 20)businessOrganization( )←. . . 21) clientWithAccount(AccountNumber)←Account : account, self(Account.issuer),AccountNumber=Account.number.22) newShippingClient(Pickup,Delivery)← Destination : contract,Warehouse : lease, knownBusiness(Destination.issuer),warehouseOwner(Warehouse.issuer), Pickup=Warehouse.location,Delivery=Destination.deliveryLocation. 23) knownBusiness( )←. . . 24)warehouseOwner( ) ←. . .

[0217] Table 4 gives role definitions that, together with thosse inTable 2, compose the authentication policies in the examples given inSection 7. We present together the authentication policies defined bythe client and the server, as some rules are used by both subjects. Notethat three rules are incomplete. Their content and the credentialsneeded to satisfyt them are elided from the example presentation to savespace.

[0218] Table 5 presents the authorization policy that governs theservice requested. In particular, Table 5 illustrates the authorizationpart of SGP for the service, “Schedule Shipping”. Parameters of theservice request include: PickupLocation, Destination, and Tons. In theexample, the client satisfies this policy by authenticating to thefollowing set of roles:

[0219] {reputation(Acme Widget, excellent), newShippingClient(AcmeWidget, HongKong, Vancouver), hasCredit(Acme Widget, $15,000)}. TABLE 5clientWithAccount(Client,AccountNumber) OR (reputation(Client,Rating)AND Rating ε {good,excellent} AND (knownClient(Client) OR(newShippingclient(Client,Pickup,Delivery) AND PickupLocation=Pickup ANDDestination = Delivery)) AND hasCredit(Client,Amount)ANDAmount≧TonsxcostPerTon(PickupLocation,Destination))

[0220]FIG. 2 shows the credentials owned by each negotiationparticipant. Each credential is labelled by a name used to refer to itin the example. Table 6 shows the CAPs of each of those credentials onlythe authorization portion of each policy is shown. The authenticationportion comprises the relevant rules from Table 2 and Table 4. Thepolicy by which the client and server, respectively, govern a credentialis deisgnated by the credential's name with subscript C and S,respectively. TABLE 6 Client Credential Access Policies:gov_(client)(Contract) = shippr(Server) AND reputation(Server,Rating)AND Rating ε {good, excellent} gov_(client)(Credit) = reputation(Server,Rating) AND Rating ε {good, excellent} gov_(client)(Warehouse) =shipper(Server) gov_(client)(B-Org-C) = true Server Credential AccessPolicies gov_(server)(Ref-1) = reputation(Client, Rating) AND Rating ε{good, excellent} gov_(server)(Ref-2) = reputation(Client, Rating) ANDRating ε {good, excellent}

[0221]FIG. 3 shows the dependencies between credentials, roles governingaccess to those credentials, and credentials that authenticate theirowner to a given role. This is presented in the form of a dependencygraph showing the client's credentials to the left, the server'scredentials to the right, client roles at the bottom, and server rolesat the top. Arcs from roles to creentials indicate that authenticatingthe role depends on verifying the credential. These arcs representauthentication policy infomraiton. Arcs from credentials to rolesindicate that the credential will be disclosed only to subjects that areauthenticated to the role. These arcs represent CAPs.

[0222] The negotiation based on the eager strategy consists of the sixstages described below (labelled EN). Following the initial request forservice in stage 1, each stage shows the unlocked credentials that aredisclosed.

[0223] EN Stage 1. Client sends (via client SA) request to scheduleshipping 5 tons of cargo from Hong Kong to Vancouver.

[0224] EN Stage 2. Server SA sends B-Org-S to client.

[0225] ENStage 3. Client SA repeats request to schedule shipping andsends B-Org-C, Credit to server.

[0226] EN Stage 4. Server SA sends B-Org-S, Ref₁, and Ref₂.

[0227] EN Stage 5. Client SA repeats service request and sends B-Org-C,

[0228] Credit, Contract, and Warehouse.

[0229] EN Stage 6. Server SA receives service request and authorizes it,as attached credentials satisfy the SGP.

[0230] The negotiation based on the parsimonious strategy consists ofthe eight stages described below (labelled PN). For each stage where anincoming request for credentials is received, the description shows thesolution to the request (a list of local-site credentials) that isselected by the SA. Credentials that are locked appear underlined in thesolution. Counter requests combine the CAPs of these locked credentials.

[0231] PN Stage 1. Client sends (via client SA) request to scheduleshipping 5 tons of cargo from Hong Kong to Vancouver.

[0232] PN Stage 2. Server SA returns the SGP (Table 4).

[0233] PN Stage 3. Client SA's solution to incoming request: Contract,Warehouse, Credit. Outgoing request for credentials: shipper(Server) ANDreputation(Server, Rating) AND Rating ∈ {good, excellent}.

[0234] PN Stage 4. Server SA's solution to incoming request: B-Org-S,Ref₁, Ref₂. Outgoing request for credentials: reputation(Client, Rating)AND Rating ∈ {good, excellent}.

[0235] PN Stage 5. The negotiation reaches the point of confidence.Client SA's solution to incoming request: B-Org-C. Outgoing request forcredentials (repeating request sent in Stage 3): shipper(Server) ANDreputation(Server, Rating) AND Rating ∈ {good, excellent}. Outgoingcredentials (which solve the request sent by server SA in Stage 4):B-Org-C.

[0236] PN Stage 6. Server SA's solution to incoming request: B-Org-S,Refl, Ref₂. Outgoing request for credentials: None. Outgoingcredentials: B-Org-S, Ref₁, Ref₂

[0237] PN Stage 7. Client SA repeats service request from Stage 1,attaching credentials that solve the SGP sent by the server SA in Stage2. Outgoing credentials: Contract, Warehouse, Credit.

[0238] PN Stage 8. Server SA receives service request and authorizes it,as attached credentials satisfy the SGP.

[0239] 8. Demonstration Prototype

[0240] We have developed a proof-of-concept demonstration prototype thatconstitutes the first implementation of trust negotiation. The prototypesupports the trivial eager negotiation strategy described in Section5.1. A description of a real-world trust negotiation scenario and thesteps of an actual trust negotiation are available at a web site havingan address which requires a user to type into a browser the phrase“http://www.” followed by the following texttransarc.com/˜trg/TrustManagement/ which is herein incorporated byreference. This section describes the prototype's system architectureand underlying technologies, as well as potential further developments.

[0241] The prototype's web-based architecture is illustrated in FIG. 4which illustrates the system architecture for a web-based demonstrationprototype of trust negotiation. Security agents serve as proxies for webclients and servers and conduct trust negotiations on their behalf inorder for strangers to establish trust and conduct secure transactionsover the web. The architecture is built around a standard web browserand web server with security agents managing credentials and accesscontrol policies for the client and server. All communication betweenthe web browser, web server, and their associated security agents isdone using HTTP. Browser requests are routed through the client securityagent. The client security agent conducts trust negotiations on behalfof the client. The agent manages the client's credentials and accesscontrol policies that govern disclosure of those credentials.

[0242] A secure web server supporting trust negotiation has anassociated security agent acting as its proxy. The security agentpermits authorized access to secure web services. It does this byverifying that client credentials are submitted that satisfy the servicegoverning policy before forwarding the request to the web server.Whenever a client requests a service without submitting sufficientcredentials to gain authorized access, the server security agentresponds by disclosing all available server credentials to the client.

[0243] The demo utilizes the Trust Establishment Package that wasdeveloped at IBM's Haifa Research Center (publicly available from a website which a user can access by typing into a browser the phrase“http://www.” followed by the phase“alphaworks.ibm.com/tech/trustestablishment”). The package providessupport for creating X.509v3 certificates, defining role-basedauthentication policies using XML, and determining whether a givensubject has a given role according to a given policy and based on a setof credentials associated with the subject. There are two features ofthe Trust Establishment Package that are purposely not utilized in thedemo. First, the Trust Establishment policy language provides supportfor requiring that a certain credential does not exist. This languagefeature is inappropriate in policies used during trust negotiation sinceeach agent controls which credentials it submits. Second, the TrustEstablishment system includes a collector used to gather relevantcredentials from remote sites. The collector assumes all credentials arefreely available, while trust negotiation treats credentials aspotentially sensitive. The trust negotiation demo assumes all relevantcredentials are available locally. Note that, unlike PAL (see Section6), TPL does not support role attributes or user defined functions.Consequently, credential expressions in our prototype to not supportthese features or constraints on service parameters.

[0244] The current implementation supports HTTP communication betweenthe web browser, web server, and their associated security agents. Theclient and server security agents are proxy servers written entirely inJava (trademark of Sun Microsystems Inc). Certificates flow in the bodyof the HTTP requests and responses in PEM (Privacy Enhanced Mail)certificate format. The agents are multi-threaded and assign a newthread to handle each incoming request.

[0245] The speed of trust negotiations will vary depending on thecredentials involved, the credential governing policies, and the servicegoverning policy. In the scenario developed for the demo, an example ofa successful trust negotiation using the eager strategy takes 8-14seconds to complete on a 400 MHz desktop computer with a Pentium IIprocessor, the Windows NT 4.0 operating system, and 190 MB of memory(Pentium II and Windows NT are trademarks of Intel Corporation andMicrosoft Corporation respectively). The example negotiation takes tworound trips between the client and server security agents, includingboth the initial client request for service and the successful finalresponse from the server granting access to the service. The finalaccess control check that the service governing policy is satisfiedverifies a credential chain of length five. The majority of the timeduring the trust negotiation is spent in the security agents using theTrust Establishment server to answer role membership questions. Thefunction to check a role membership averages 2-5 seconds in the scenariowe developed. The Trust Establishment system is a research prototypethat has not yet been fine-tuned for high performance.

[0246] There are several further extensions desirable for the currentprototype to be used in a production environment. The prototypecurrently lacks a mechanism for a subject to prove ownership of a publickey. In practice, a security agent must authenticate the subjectsubmitting a credential chain to be the owner of the leaf credential inthe chain. One potential solution is to incorporate SSL as thecommunication protocol between client and server security agentsconducting a trust negotiation. SSL client and server authentication canbe used to verify ownership of the public key of both client and server.This solution imposes the restriction that all credentials owned by asubject that are used for trust negotiation during an SSL session mustcontain the same public key.

[0247] The prototype supports credential and service authorizationpolicies as a single, atomic role definition. This capability can beextended to support authorization policies consisting of a monotonicBoolean combination of roles. A simple authorization policy languagecould be defined using XML, similar to how authentication policies arecurrently represented.

[0248] The prototype stores credentials and policies in flat files. Analternative is to store them in an LDAP directory. The current prototypeassumes all supporting credentials are available to the security agentlocally. This assumption could be relaxed to support distributed,on-demand gathering of supporting credentials. The Trust EstablishmentServer from the IBM Haifa Research Lab has a collector feature thatsupports this functionality. The collector assumes all credentials arefreely available. In the future, it is planned to investigate enhancingthe collector by using trust negotiation to manage sensitivecredentials.

[0249] 9. Conclusions and Further Work

[0250] The model and architecture disclosed herein can be used fornegotiating mutual trust between clients and servers through anincremental exchange of potentially sensitive credentials. Twonegotiation strategies have been presented, one eager with credentialdisclosures and one parsimonious. The eager strategy negotiatesefficiently, succeeding whenever possible. Its participants exchange nocredential requests, nor otherwise atempt to minimize credentialdisclosures. The drawback is that many credentials are disclosedunnecessarily. However, the strategy reveals no information about anycredential that a subject possesses until the credential's CAP issatisfied. There is an advantage in this: credential requests exchangedin the parsimonious strategy could in principle reveal a great dealabout which credentials a subject has.

[0251] The parsimonious strategy conducts a minimal-length exchange inwhich each disclosure is a locally minimal set. It does this byconducting an exchange of credential requests that in effect considersevery possible successful exchange. It remains open how to ensure thatthe union of each participant's disclosures is minimal, or whether thisis even possible. A strategy that achieves global minimality ofcredential disclosures in this sense remains a goal.

[0252] The strategies presented here assume that both participantscooperate in using the strategy. Further research is required todetermine whether and how that assumption can be relaxed or welljustified. A parsimonious negotiation guarantees locally minimalcredential disclosure only when both parties “bargain in good faith”.This means that each SA assumes the following about the other SA. Whenthe other SA responds to an incoming request by issuing a counterrequest, if that SA subsequently receives credentials that satisfy thecounter request, together with a repetition of the original request, itwill return credentials that satisfy that original request. Oneadvantage of a hybrid negotiation strategy, such as the one suggested inSection 5.3, is that the eager phase could be used to establish trustthat the other negotiation partner will bargain in good faith beforeentering a parsimonious negotiation.

[0253] The architecture presented herein addresses some, but notnecessarily all, of the client's trust needs. It addresses the client'sneed for trust that enables it to disclose credentials to the server,but not the client's need for trust before it requests the service. Thearchitecture could assist in negotiating the server's disclosure ofcredentials that would establish that trust. However the questionremains of how the client formulates its request for those credentials.Such a request could be based, for instance, on transaction type or onthe contents of service request parameters. Another open area concernsmanagement of policy information. Negotiation strategies that exchangemobile policy content introduce trust issues that have not yet beenaddressed. Policy owners may need to protect sensitive policy content.Security agents receiving mobile policy content may need to verify itsauthenticity and integrity.

[0254] Further research can also be usefully directed to dimensions ofcredential-governing policy that determine or influence negotiationstrategy. In addition to the credential expression whose satisfactionunlocks credential disclosure, additional policy content may assist indetermining credential disclosures and requests. Two orthogonal issuesthat a credential-governing policy might address are as follows. Thefirst is whether voluntary credential disclosure is permitted wheneverthe credential is unlocked or whether the credential must first beexplicitly requested (presumably implying that its disclosure isnecessary for successful negotiation). The second is whether it ispermitted to issue counter requests when the credential is requested,potentially disclosing that the credential is held without disclosingthe credential itself. The hybrid strategy presented in Section 5.3assumes that each credential either can be voluntarily disclosed or canhave a counter request issued in an effort to unlock it. A naturalgeneralization captures the other two possibilities: that a credential(1) can both be voluntarily disclosed and have counter requests issuedand (2) can neither be voluntarily disclosed nor have counter requestsissued. It seems intuitive that some credentials would naturally fallinto each of these categories, based, for instance, on whetherpossession or contents of the credential were more sensitive, and thereasons for the sensitivity.

[0255] The potential impact of these policy concepts on hybridnegotiation strategies needs to be examined further. Credentials in the“both” category might enable flexible and focused strategies. Strategiesare needed that manage disclosure of credentials whose highly sensitivenature requires the “neither” category.

[0256] These credentials should only be disclosed to a partner thatrequests them and that simultaneously provides sufficient credentials tounlock them. For instance, this could be accomplished by a hybridstrategy with an eager negotiation phase followed by a single requestfor the most sensitive credentials.

[0257] Another policy generalization would group credentials intoordered sensitivity classes. This captures a notion of relativesensitivity not captured by other policy constructs above. Strategiescould prefer disclosing credentials in lower sensitivity classes.

[0258] The architecture presented here addresses some, but not all, ofthe client's trust needs. It addresses the client's need for trust thatenables it to disclose credentials to the server. It does not addressthe client's need for trust before it requests service. The architecturecould assist in negotiating the server's disclosure of credentials thatwould establish that trust. However, further work is needed to addressthe question of how the client formulates its request for thosecredentials. Such a request could be based, for instance, on transactiontype or on the contents of service request parameters. Further work isalso desirable in the management of policy information. Negotiationstrategies that exchange mibile policy content introduce trust issuesthat have not yet been addressed. Policy owners may need to protectsensitive policy content. Security agents receiving mobile policycontent may need to verify its authenticity and integrity.

[0259] 9.1 Influences on Strategy

[0260] Further research can be usefully directed to dimensions ofcredential-governing policy that determine or influence negotiationstrategy. In addition to the credential expression whose satisfactionunlocks credential disclosure, additional policy content may assist indetermining credential disclosures and requests. Two orthogonal issuesthat a credential-governing policy might address are as follows. Thefirst is whether voluntary credential disclosure is permitted wheneverthe credential is unlocked or only when the credential is part of asolution to an explicit credential request (presumably implying thatdisclosure of some solution is necessary for successful negotiation).The second is whether it is permitted to issue counter requests when thecredential is requested, potentially disclosing that the credential isheld without disclosing the credential itself. The hybrid strategypresented in Section 5.3 assumes that each credential either can bevoluntarily disclosed or can have a counter request issued in an effortto unlock it. A natural generalization captures the other twopossibilities: that a credential (1) can both be voluntarily disclosedand have counter requests issued and (2) can neither be voluntarilydisclosed nor have counter requests issued. It seems intuitive that somecredentials would naturally fall into each of these categories, based,for instance, on whether possession or contents of the credential weremore sensitive, and the reasons for the sensitivity.

[0261] The potential impact of these policy concepts on hybridnegotiation strategies needs to be examined further. Credentials in the“both” category might enable flexible and focused strategies. Strategiesare needed that manage disclosure of credentials whose highly sensitivenature requires the “neither” category. These credentials should only bedisclosed to a partner that requests them and that simultaneouslyprovides sufficient credentials to unlock them. For instance, this couldbe accomplished by a hybrid strategy with an eager negotiation phasefollowed by a single request for the most sensitive credentials.

[0262] Another policy generalization would group credentials intoordered sensitivity classes. This captures a notion of relativesensitivity not captured by other policy constructs above. Strategiescould prefer disclosing credentials in lower sensitivity classes.

[0263] Dynamic factors such as urgency to establish trust may haveimportant influence on strategy in future trust negotiation systems. Forinstance, the client might determine an urgency factor at the outset ofnegotiation. This would be an integer drawn from a range of valuesrepresenting the importance the client associates with obtaining asuccessful negotiation outcome. The two dimensions of policy contentdiscussed above—permission to voluntarily disclose and permission toissue counter requests—would be represented by integers in the samerange of values as the urgency factor. These would be interpreteddynamically during negotiation by comparing them with the currenturgency factor to determine whether permission is granted.

[0264] Property-based authentication is useful not only when client andserver are complete strangers. When multiple organizations formcoalitions, such as business partnerships, it may be possible by usingproperty-based authentication to reduce the administrative overhead thatchanges in coalition membership require. The idea is to authenticate thesubject within a partner organization in terms of the subject's rolewithin its home organization, as documented by credentials issued by thehome organization. Policies written by the home organization would beused to interpret the credentials issued there. Partner organizationswishing to authenticate the subject would need to define their own rolesin terms of the roles defined by the subject's home-organization.

[0265] This arrangement raises some interesting linguistic issues. PALand TPL role definitions define and use roles held by others in relationto the self—the entity enforcing the policy. A policy written at adifferent organization defines roles in relation to that otherorganization. PAL and TPL currently have no provisions for definingroles held in relation to the self in terms of roles held in relation toothers. In addition to this capability, a further requirement is supportfor differences in nomenclature used to refer to essentially similarroles at different organizations. A natural solution here is to addfirst-class roles to the policy language as parametric binary relations.By allowing roles held in relation to others to be used by and passed asparameters into role definitions, we obtain late binding ofpartner-organization authentication policies, as well as avoidingproblems of differing naming conventions between partner organizations.An important issue for trust negotiation will be the impact of thesefeatures on the complexity of deriving counter requests in theparsimonious strategy.

[0266] The present invention is preferably embodied as a computerprogram product for use with a computer system. Such an implementationmay comprise a series of computer readable instructions either fixed ona tangible medium, such as a computer readable media, e.g., diskette,CD-ROM, ROM, or hard disk, or transmittable to a computer system, via amodem or other interface device, over either a tangible medium,including but not limited to optical or analog communications lines, orintangibly using wireless techniques, including but not limited tomicrowave, infrared or other transmission techniques. The series ofcomputer readable instructions embodies all or part of the functionalitypreviously described herein.

[0267] Those skilled in the art will appreciate that such computerreadable instructions can be written in a number of programminglanguages for use with many computer architectures or operating systems.Further, such instructions may be stored using any memory technology,present or future, including but not limited to, semiconductor,magnetic, or optical, or transmitted using any communicationstechnology, present or future, including but not limited to optical,infrared, or microwave. It is contemplated that such a computer programproduct may be distributed as a removable media with accompanyingprinted or electronic documentation, e.g., shrink wrapped software,pre-loaded with a computer system, e.g., on a system ROM or fixed disk,or distributed from a server or electronic bulletin board over anetwork, e.g., the Internet or World Wide Web.

[0268] References

[0269] (nb url's are presented with // replaced by “zz?” to render notdirectly operative).

[0270] [1] E. Bina, V. Jones, R. McCool, and M. Winslett, “Secure Accessto Data Over the Internet,” Proceedings of the Third ACM/IEEEInternational Conference on Parallel and Distributed InformationSystems, Austin, Tex., September 1994.

[0271] [2] M. Blaze, J. Feigenbaum, J. Ioannidis, and A. Keromytis, “TheKeyNote Trust Management System,” work in progress, Internet Draft,March 1999.

[0272] [3] M. Blaze, J. Feigenbaum, and A. D. Keromytis, “KeyNote: TrustManagement for Public-Key Infrastructures,” Cambridge 1998 SecurityProtocols International Workshop, England, 1998.

[0273] [4] M. Blaze, J. Feigenbaum, and J. Lacy, “Decentralized TrustManagement,” 1996 IEEE Conference on Privacy and Security, Oakland 1996.

[0274] [5] N. Ching, V. Jones, and M. Winslett, “Authorization in theDigital Library: Secure Access to Services across EnterpriseBoundaries,” Proceedings of ADL '96—Forum on Research and TechnologyAdvances in Digital Libraries, Washington, D.C., May 1996. Available athttp:zz?drl.cs.uiuc.edu/security/pubs.html.

[0275] [6] T. Dierks, C. Allen, “The TLS Protocol Version 1.0,”draft-ietf-tls-protocol-06.txt, Nov. 12, 1998.

[0276] [7] S. Farrell, “TLS Extensions for Attribute Certificate BasedAuthorization,” draft-ietf-tls-attr-cert-01.txt, Aug. 20, 1998.

[0277] [8] A. Frier, P. Karlton, and P. Kocher, “The SSL 3.0 Protocol,”Netscape Communications Corp., November 1996.

[0278] [9] N. Li, J. Feigenbaum, and B Grosof, “A Logic-based KnowledgeRepresentation for Authorization with Delegation” (Extended Abstract),Proceedings of the 12th Computer Security Foundations Workshop, IEEEComputer Society Press, Los Alamitos, 1999, pp. 162-174. Full paperavailable as IBM Research Report RC21492(96966).

[0279] [10] N. Li, B Grosof and J Feigenbaum, “A PracticallyImplementable and Tractable Delegation Logic”, to appear in Proceedingsof the 2000 IEEE Sumposium on Security and Privacy.

[0280] [11] W. Johnston, S. Mudumbai, and M. Thompson, “Authorizationand Attribute Certificates for Widely Distributed Access Control,”Proceedings of the IEEE 7th International Workshops on EnablingTechnologies: Infrastructure for Collaborative Enterprises-WETICE '98.

[0281] [12] A. Herzberg, J. Mihaeli, Y Mass, D. Naor, and Y. Ravid,“Access Control Meets Public Key Infrastructure, Or: Assigning Roles toStrangers,” forthcoming, IBM Haifa Research Laboratory(http:zz?www.hrl.il.ibm.com

[0282] [13] “The Trust Policy Language,” IBM Haifa Research Laboratory(http:zz?www.hrl.il.ibm.com/).

[0283] [14] B. Schneier, Applied Cryptography, John Wiley and Sons,Inc., second edition, 1996.

[0284] [15] K. Seamons, W. Winsborough, and M. Winslett, “InternetCredential Acceptance Policies,” Proceedings of the 2nd InternationalWorkshop on Logic Programming Tools for Internet Applications. Leuven,Belgium, July 1997. Available athttp:zz?clement.info.umoncton.ca/˜lpnet/proceedings97/.

[0285] [16] W. Winsborough, K. Seamons, and V. Jones, “Automated TrustNegotiation: Managing Disclosure of Sensitive Credentials”, TransarcResearch White Paper, May 1999.

[0286] [17] W. Winsborough, K. Seamons, and V. Jones, “NegotiatingDisclosure of Sensitive Credentials,” Second Conference on Security inCommunication Networks '99, Amalfi, Italy, September 1999.

[0287] [18] W. Winsborough, K. Seamons, and V. Jones, “Automated TrustNegotiation” DARPA Information Survivability Conference and Exposition(DISCEX'2000), January 2000.

[0288] [19] M. Winslett, N. Ching, V. Jones, and I. Slepchin, “UsingDigital Credentials on the World-Wide Web,” Journal of ComputerSecurity, 5, 1997, 255-267. Available athttp:zz?drl.cs.uiuc.edu/security/pubs.html.

[0289] [20] P. Zimmerman, PGP User's Guide, MIT Press, Cambridge, 1994.

[0290] [21] Simple Public Key Infrastructure (SPKI),http:zz?www.ietf.org/html.charters/spki-charter.html.

[0291] [22] International Telecommunication Union, RecommendationX.509—Information Technology—Open Systems Interconnection—The Directory:Authentication Framework, August 1997.

We claim:
 1. A method of performing automated trust negotiations betweenfirst and second parties connected over a network, said methodcomprising the steps of: providing each party with a set of credentials,wherein a credential provides an authorization of a property of itsrespective party; classifying one or more credentials in the set ofcredentials for said first party as sensitive, such that they can onlybe disclosed to another party subject to certain predetermined criteria;establishing negotiations over the network between said first and secondparties in order to complete a desired transaction, wherein saidtransaction is only authorized to proceed if at least one of the partiesreceives certain predetermined credentials from the other party; andtransmitting at least one of the one or more sensitive credentials fromthe first party to the second party as part of said negotiations,subject to the first party previously receiving from the second partyone or more credentials that satisfy said certain predeterminedcriteria; wherein said first and second parties are a server and aclient respectively, wherein said server is to perform the desiredtransaction in response to a request from the client; wherein the serverspecifies a set of credentials that it must receive from a client inorder to set up or perform the transaction; wherein both the client andthe server have one or more credentials in their respective sets ofcredentials which are classified as sensitive, such that they can onlybe disclosed to another party subject to certain predetermined criteria;wherein the negotiations over the network between the client and theserver in order to complete a desired transaction include transmittingat least one of the one or more sensitive credentials from the client tothe server as part of said negotiations, subject to the clientpreviously receiving from the server one or more credentials thatsatisfy said certain predetermined criteria for the client; wherein atleast one party adopts an eager strategy, according to which allsensitive credentials are transmitted to the other party subject only toreceipt of certain predetermined credentials from the other party,irrespective of whether or not transmission of such sensitivecredentials is necessary in order to complete said transaction; andwherein at least one party adopts a parsimonious strategy, according towhich only selected sensitive credentials are transmitted to the otherparty from the set of sensitive credentials that could be transmittedafter receipt of certain predetermined credentials from the other party,said selection being performed on the basis of transmitting only thosesensitive credentials that are specifically necessary in order tocomplete said transaction.
 2. The method of claim 1, wherein said firstand second parties are a client and a server respectively, wherein saidserver is to perform the desired transaction in response to a requestfrom the client.
 3. The method of claim 2, wherein in order to set up orperform the transaction, the client is required to supply at least oneof the one or more sensitive credentials to the server.
 4. The method ofclaim 1, wherein said parsimonious strategy involves the exchange ofcredential requests to establish a point of confidence prior totransmission of credentials themselves.
 5. The method of claim 1,wherein at least one party initially adopts an eager strategy, accordingto which all sensitive credentials are transmitted to the other partysubject only to receipt of certain predetermined credentials from theother party, irrespective of whether or not transmission of suchsensitive credentials is necessary in order to complete saidtransaction, and then at a later stage of said negotiations subsequentlyadopts a parsimonious strategy, according to which only selectedsensitive credentials are transmitted to the other party from the set ofsensitive credentials that could be transmitted after receipt of certainpredetermined credentials from the other party, said selection beingperformed on the basis of transmitting only those sensitive credentialsthat are specifically necessary in order to complete said transaction.6. The method of claim 1, wherein said server defines a servicegoverning policy that specifies certain roles, such that said client canonly set up or perform the transaction if it has sufficient credentialsto allow it to assume one of said certain roles.
 7. A computer programproduct stored on a computer readable storage medium for, when run on acomputer system, carrying out the method of claim
 1. 8. A dataprocessing apparatus for use in performing automated trust negotiationsbetween first and second parties connected over a network, the apparatuscomprising: means for providing a party with a set of credentials,wherein a credential provides an authorization of a property of itsrespective party; means for classifying one or more credentials in theset of credentials for said first party as sensitive, such that they canonly be disclosed to another party subject to certain predeterminedcriteria; means for establishing negotiations over the network betweensaid first and second parties in order to complete a desiredtransaction, wherein said transaction is only authorized to proceed ifat least one of the parties receives certain predetermined credentialsfrom the other party; and means for transmitting at least one of the oneor more sensitive credentials from the first party to the second partyas part of said negotiations, subject to the first party previouslyreceiving from the second party one or more credentials that satisfysaid certain predetermined criteria; wherein said first and secondparties are a server and a client respectively, wherein said server isto perform the desired transaction in response to a request from theclient; wherein the server specifies a set of credentials that it mustreceive from a client in order to set up or perform the transaction;wherein both the client and the server have one or more credentials intheir respective sets of credentials which are classified as sensitive,such that they can only be disclosed to another party subject to certainpredetermined criteria; wherein the negotiations over the networkbetween the client and the server in order to complete a desiredtransaction include transmitting at least one of the one or moresensitive credentials from the client to the server as part of saidnegotiations, subject to the client previously receiving from the serverone or more credentials that satisfy said certain predetermined criteriafor the client; wherein at least one party adopts an eager strategy,according to which all sensitive credentials are transmitted to theother party subject only to receipt of certain predetermined credentialsfrom the other party, irrespective of whether or not transmission ofsuch sensitive credentials is necessary in order to complete saidtransaction; and wherein at least one party adopts a parsimoniousstrategy, according to which only selected sensitive credentials aretransmitted to the other party from the set of sensitive credentialsthat could be transmitted after receipt of certain predeterminedcredentials from the other party, said selection being performed on thebasis of transmitting only those sensitive credentials that arespecifically necessary in order to complete said transaction.